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Abstract 


This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A 
manifest is a signed object (file) that contains a listing of all the signed objects (files) in the 
repository publication point (directory) associated with an authority responsible for publishing 
in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed 
objects issued by the authority that are published at this repository publication point, the 
manifest contains both the name of the file containing the object anda hash of the file content. 
Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a 
repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved 
from a repository publication point, then the RP can detect replay attacks, and unauthorized in- 
flight modification or deletion of signed objects. This document obsoletes RFC 6486. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and howto provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc9286. 


Copyright Notice 


Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights 
reserved. 
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This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Revised BSD License. 
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1. Introduction 


The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of a distributed repository 
system [RFC6481] to make available a variety of objects needed by relying parties (RPs). Because 
all of the objects stored in the repository system are digitally signed by the entities that created 
them, attacks that modify these published objects are detectable by RPs. However, digital 
signatures alone provide no protection against attacks that substitute "stale" versions of signed 
objects (i.e., objects that were valid and have not yet expired, but have since been superseded), or 
in-flight attacks that remove an object that should be present in the repository. To assist in the 
detection of such attacks, RPKI repository systems make use of a signed object calleda 
"manifest". 


A manifest is a signed object that enumerates all the signed objects (files) in the repository 
publication point (directory) that are associated with an authority responsible for publishing at 
that publication point. Each manifest contains both the name of the file containing the object 
and a hash of the file content, for every signed object issued by an authority that is published at 
the authority's repository publication point. A manifest is intended to allow an RP to detect 
unauthorized object removal or the substitution of stale versions of objects at a publication point. 
A manifest also is intended to allow an RP to detect similar outcomes that may result from an on- 
path attack during the retrieval of objects from the repository. Manifests are intended to be used 
in Certification Authority (CA) publication points in repositories (directories containing files that 
are subordinate certificates and Certificate Revocation Lists (CRLs) issued by this CA and other 
signed objects that are verified by End-Entity (EE) certificates issued by this CA). 


Manifests are modeled on CRLs, as the issues involved in detecting stale manifests and potential 
attacks using manifest replays, etc., are similar to those for CRLs. The syntax of the manifest 
payload differs from CRLs, since RPKI repositories contain objects not covered by CRLs, e.g., 
digitally signed objects, such as Route Origin Authorizations (ROAs) [RFC6482]. 


This document obsoletes [RFC6486]. 
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1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


2. Manifest Scope 


A manifest associated with a CA's repository publication point contains a list of: 


e the set of (non-expired, non-revoked) certificates issued and published by this CA, 
e the most recent CRL issued by this CA, and 


e all published signed objects that are verifiable using EE certificates [RFC6487] issued by this 
CA (other than the manifest itself). 


Every RPKI signed object includes, in the Cryptographic Message Syntax (CMS) [RFC5652] 
wrapper of the object, the EE certificate used to verify it [RFC6488]. Thus, there is no requirement 
to separately publish that EE certificate at the CA's repository publication point. 


Where multiple CA instances share a common publication point, as can occur when a CA 
performs a key-rollover operation [RFC6489], the repository publication point will contain 
multiple manifests. In this case, each manifest describes only the collection of published products 
of its associated CA instance. 


3. Manifest Signing 


A CA's manifest is verified using an EE certificate. The SubjectInfoAccess (SIA) field of this EE 
certificate contains the accessMethod Object Identifier (OID) of id-ad-signedObject. 


The CA MUST sign only one manifest with each generated private key and MUST generate a new 
key pair for each new version of the manifest. An associated EE certificate used in this fashion is 
termed a "one-time-use" EE certificate (see Section 3 of [RFC6487]). 


4. Manifest Definition 


A manifest is an RPKI signed object, as specified in [RFC6488]. The RPKI signed object template 
requires specification of the following data elements in the context of the manifest structure. 


4.1. eContentType 


The eContentType for a manifest is defined as id-ct-rpkiManifest and has the numerical OID of 
1.2.840.113549.1.9.16.1.26. 
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id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 
rsadsi(113549) pkcs(1) pkcs9(9) 16 } 


id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 


id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 


4.2. eContent 


The content of a manifest is ASN.1 encoded using the Distinguished Encoding Rules (DER) [X.690]. 
The content of a manifest is defined as follows: 


Manifest ::= SEQUENCE { 
version [@] INTEGER DEFAULT @, 
manifestNumber INTEGER (@..MAX), 
thisUpdate GeneralizedTime, 
nextUpdate GeneralizedTime, 
fileHashAlg OBJECT IDENTIFIER, 
fileList SEQUENCE SIZE (@..MAX) OF FileAndHash 
} 

FileAndHash ::= SEQUENCE { 
file TA5String, 
hash BIT STRING 


4.2.1. Manifest 


The manifestNumber, thisUpdate, and nextUpdate fields are modeled after the corresponding 
fields in X.509 CRLs (see [RFC5280]). Analogous to CRLs, a manifest is nominally current until the 
time specified in nextUpdate or until a manifest is issued with a greater manifest number, 
whichever comes first. 


Because a "one-time-use" EE certificate is employed to verify a manifest, the EE certificate MUST 
be issued with a validity period that coincides with the interval from thisUpdate to nextUpdate in 
the manifest, to prevent needless growth of the CA's CRL. 


The data elements of the manifest structure are defined as follows: 


version: 
The version number of this version of the manifest specification MUST be 0. 


manifestNumber: 
This field is an integer that is incremented (by 1) each time a new manifest is issued for a given 
publication point. This field allows an RP to detect gaps in a sequence of published manifests. 


As the manifest is modeled on the CRL specification, the manifestNumber is analogous to the 
CRLNumber, and the guidance in [RFC5280] for CRLNumber values is appropriate as to the 
range of number values that can be used for the manifestNumber. Manifest numbers can be 
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expected to contain long integers. Manifest verifiers MUST be able to process number values 
up to 20 octets. Conforming manifest issuers MUST NOT use number values longer than 20 
octets. The issuer MUST increase the value of this field monotonically for each newly 
generated manifest. Each RP MUST verify that a purported "new" manifest contains a higher 
manifestNumber than previously validated manifests. If the purported "new" manifest 
contains a manifestNumber value equal to or lower than manifestNumber values of 
previously validated manifests, the RP SHOULD use locally cached versions of objects, as 
described in Section 6.6. 


thisUpdate: 
This field contains the time when the manifest was created. This field has the same format 
constraints as specified in [RFC5280] for the CRL field of the same name. The issuer MUST 
ensure that the value of this field is more recent than any previously generated manifest. Each 
RP MUST verify that this field value is greater (more recent) than the most recent manifest it 
has validated. If this field in a purported "new" manifest is smaller (less recent) than 
previously validated manifests, the RP SHOULD use locally cached versions of objects, as 
described in Section 6.6. 


nextUpdate: 
This field contains the time at which the next scheduled manifest will be issued. The value of 
nextUpdate MUST be later than the value of thisUpdate. The specification of the 
GeneralizedTime value is the same as required for the thisUpdate field. 


If the authority alters any of the items that it has published in the repository publication point, 
then the authority MUST issue a new manifest. Even if no changes are made to objects at a 
publication point, a new manifest MUST be issued before the nextUpdate time. Each manifest 
encompasses a CRL, and the nextUpdate field of the manifest SHOULD match that of the CRL's 
nextUpdate field, as the manifest will be reissued when a new CRL is published. When a new 
manifest is issued before the time specified in nextUpdate of the current manifest, the CA 
MUST also issue a new CRL that revokes the EE certificate corresponding to the old manifest. 


fileHashAlg: 
This field contains the OID of the hash algorithm used to hash the files that the authority has 
placed into the repository. The hash algorithm used MUST conform to the RPKI Algorithms and 
Key Size Profile specification [RFC7935]. 


fileList: 
This field is a sequence of FileAndHash objects. There is one FileAndHash entry for each 
currently valid signed object that has been published by the authority (at this publication 
point). Each FileAndHash is an ordered pair consisting of the name of the file in the repository 
publication point (directory) that contains the object in question and a hash of the file's 
contents. 
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4.2.2. Names in FileAndHash Objects 


Names that appear in the fileList MUST consist of one or more characters chosen from the set a-z, 
A-Z, 0-9, - (HYPHEN), or__(UNDERSCORE), followed by a single . (DOT), followed by a three- letter 
extension. The extension MUST be one of those enumerated in the "RPKI Repository Name 
Schemes" registry maintained by IANA [[ANA-NAMING]. 


As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid file name. 


The example above contains a mix of uppercase and lowercase characters in the file name. CAs 
and RPs MUST be able to perform filesystem operations in a case-sensitive, case-preserving 
manner. 


4.3. Content-Type Attribute 


The mandatory content-type attribute MUST have its attrValues field set to the same OID as 
eContentType. This OID is id-ct-rpkiManifest and has the numerical value of 
1.2.840.113549.1.9.16.1.26. 


4.4. Manifest Validation 
To determine whether a manifest is valid, the RP MUST perform the following checks in addition 


to those specified in [RFC6488]: 


1. The eContentType in the EncapsulatedContentInfo is id-ad- rpkiManifest (OID 
1.2.840.113549.1.9.16.1.26). 


2. The version of the rpkiManifest is 0. 
3. In the rpkiManifest, thisUpdate precedes nextUpdate. 


Note: Although the thisUpdate and nextUpdate fields in the manifest eContent MUST match the 
corresponding fields in the CRL associated with the manifest, RPs MUST NOT reject a manifest 
solely because these fields are not identical. 


If the above procedure indicates that the manifest is invalid, then the manifest MUST be discarded 
and treated as though no manifest were present. 


5. Manifest Generation 


5.1. Manifest Generation Procedure 


Fora CA publication point in the RPKI repository system, a CA MUST perform the following steps 
to generate a manifest: 


1. Generate a new key pair for use in a "one-time-use" EE certificate. 


2. Issue an EE certificate for this key pair. The CA MUST revoke the EE certificate used for the 
manifest being replaced. 
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This EE certificate MUST have an SIA extension access description field with an accessMethod 
OID value of id-ad-signedObject, where the associated accessLocation references the 
publication point of the manifest as an object URL. (RPs are required to verify both of these 
syntactic constraints.) 


This EE certificate MUST describe its Internet Number Resources (INRs) using the "inherit" 
attribute, rather than an explicit description of a resource set (see [RFC3779]). (RPs are 
required to verify this.) 


The validity interval of the EE certificate MUST exactly match the thisUpdate and nextUpdate 
times specified in the manifest's eContent. (An RP MUST NOT consider misalignment of the 
validity interval in and of itself to be an error.) 


3. The EE certificate MUST NOT be published in the authority's repository publication point. 
4. Construct the manifest content. 


The manifest content is described in Section 4.2.1. The manifest's fileList includes the file 
name and hash pair for each object issued by this CA that has been published at this 
repository publication point (directory). The collection of objects to be included in the 
manifest includes all certificates issued by this CA that are published at the CA's repository 
publication point, the most recent CRL issued by the CA, and all objects verified by EE 
certificates that were issued by this CA that are published at this repository publication point. 
(Sections 6.1 through 6.5 describe the checks that an RP MUST perform in support of the 
manifest content noted here.) 


Note that the manifest does not include a self reference (i.e., its own file name and hash), 
since it would be impossible to compute the hash of the manifest itself prior to it being signed. 


5. Encapsulate the manifest content using the CMS SignedData content type (as specified in 
Section 4), sign the manifest using the private key corresponding to the subject key contained 
in the EE certificate, and publish the manifest in the repository system publication point that 
is described by the manifest. (RPs are required to verify the CMS signature.) 


6. Because the key pair is to be used only once, the private key associated with this key pair 
MUST now be destroyed. 


5.2. Considerations for Manifest Generation 


Anew manifest MUST be issued and published before the nextUpdate time. 


An authority MUST issue a new manifest in conjunction with the finalization of changes made to 
objects in the publication point. If any named objects in the publication point are replaced, the 
authority MUST ensure that the file hash for each replaced object is updated accordingly in the 
new manifest. Additionally, the authority MUST revoke the certificate associated with each 
replaced object (other than a CRL), if it is not expired. An authority MAY perform a number of 
object operations on a publication repository within the scope of a repository change before 
issuing a single manifest that covers all the operations within the scope of this change. Repository 
operators MUST implement some form of repository update procedure that mitigates, to the 
extent possible, the risk that RPs that are performing retrieval operations on the repository are 
exposed to inconsistent, transient, intermediate states during updates to the repository 
publication point (directory) and the associated manifest. 
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Since the manifest object URL is included in the SIA of issued certificates, anew manifest MUST 
NOT invalidate the manifest object URL of previously issued certificates. This implies that the 
manifest's publication name in the repository, in the form of an object URL, is unchanged across 
manifest generation cycles. 


When a CA entity is performing a key rollover, the entity MAY choose to have two CA instances 
simultaneously publishing into the same repository publication point. In this case, there will be 
one manifest associated with each active CA instance that is publishing into the common 
repository publication point (directory). 


6. Relying Party Processing of Manifests 


Each RP MUST use the current manifest of a CAto control addition of listed files to the set of 
signed objects the RP employs for validating basic RPKI objects: certificates, ROAs, and CRLs. Any 
files not listed on the manifest MUST NOT be used for validation of these objects. However, files 
not listed on a manifest MAY be employed to validate other signed objects, if the profile of the 
object type explicitly states that such behavior is allowed (or required). Note that relying on files 
not listed in a manifest may allowan attacker to effect substitution attacks against such objects. 


As noted earlier, manifests are designed to allow an RP to detect manipulation of repository data, 
errors by a CA or repository manager, and/or active attacks on the communication channel 
between an RP and a repository. Unless all of the files enumerated in a manifest can be obtained 
by an RP during a fetch operation, the fetch is considered to have failed and the RP MUST retry the 
fetch later. 


[RFC6480] suggests (but does not mandate) that the RPKI model employ fetches that are 
incremental, e.g., an RP transfers files from a publication point only if they are new/changed 
since the previous, successful fetch represented in the RP's local cache. This document avoids 
language that relies on details of the underlying file transfer mechanism employed by an RP and 
a publication point to effect this operation. Thus, the term "fetch" refers to an operation that 
attempts to acquire the full set of files at a publication point, consistent with the id-ad- 
rpkiManifest URI extracted from a CA certificate's SIA (see below). 


If a fetch fails, it is assumed that a subsequent fetch will resolve problems encountered during the 
fetch. Until such time as a successful fetch is executed, an RP SHOULD use cached data from a 
previous, successful fetch. This response is intended to prevent an RP from misinterpreting data 
associated with a publication point and thus possibly treating invalid routes as valid, or vice 
versa. 


The processing described below is designed to cause all RPs with access to the same local cache 
and RPKI repository data to acquire the same set of validated repository files. It does not ensure 
that the RPs will achieve the same results with regard to validation of RPKI data, since that 
depends on how each RP resolves any conflicts that may arise in processing the retrieved files. 
Moreover, in operation, different RPs will access repositories at different times, and some RPs 
may experience local cache failures, so there is no guarantee that all RPs will achieve the same 
results with regard to acquisition or validation of RPKI data. 
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Note also that there is a "chicken and egg" relationship between the manifest and the CRL fora 
given CA instance. If the EE certificate for the current manifest is revoked, i.e., it appears in the 
current CRL, then the CA or publication point manager has made a serious error. In this case, the 
fetch has failed; proceed to Section 6.6. Similarly, if the CRL is not listed on a valid, current 
manifest, acquired during a fetch, the fetch has failed; proceed to Section 6.6, because the CRL is 
considered missing. 


6.1. Manifest Processing Overview 


For a given publication point, an RP MUST perform a series of tests to determine which signed 
object files at the publication point are acceptable. The tests described below (Sections 6.2 through 
6.5) are to be performed using the manifest identified by the id-ad- rpkiManifest URI extracted 
from a CA certificate's SIA. All of the files referenced by the manifest MUST be located at the 
publication point specified by the id-ad-caRepository URI from the (same) CA certificate's SIA. The 
manifest and the files it references MUST reside at the same publication point. If an RP 
encounters any files that appear on a manifest but do not reside at the same publication point as 
the manifest, the RP MUST treat the fetch as failed, and a warning MUST be issued (see Section 6.6 
below). 


Note that, during CA key rollover [RFC6489], signed objects for two or more different CA instances 
will appear at the same publication point. Manifest processing is to be performed separately for 
each CA instance, guided by the SIA id-ad-rpkiManifest URI in each CA certificate. 


6.2. Acquiring a Manifest for a CA 


The RP MUST fetch the manifest identified by the SIA id-ad- rpkiManifest URI in the CA certificate. 
If an RP cannot retrieve a manifest using this URI or if the manifest is not valid (Section 4.4), an 
RP MUST treat this as a failed fetch; proceed to Section 6.6. Otherwise, proceed to Section 6.3. 


6.3. Detecting Stale and/or Prematurely Issued Manifests 


The RP MUST check that the current time (translated to UTC) is between thisUpdate and 
nextUpdate. If the current time lies within this interval, proceed to Section 6.4. If the current time 
is earlier than thisUpdate, the CA may have made an error or the RP's local notion of time may be 
in error. The RP MUST treat this as a failed fetch; proceed to Section 6.6. If the current time is later 
than nextUpdate, then the manifest is stale; the RP MUST treat this as a failed fetch. Proceed to 
Section 6.6. Otherwise, proceed to Section 6.4. 


6.4. Acquiring Files Referenced by a Manifest 


The RP MUST acquire all of the files enumerated in the manifest (fileList) from the publication 
point. If there are files listed in the manifest that cannot be retrieved from the publication point, 
the RP MUST treat this as a failed fetch. Proceed to Section 6.6. Otherwise, proceed to Section 6.5. 
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6.5. Matching File Names and Hashes 


The RP MUST verify that the hash value of each file listed in the manifest matches the value 
obtained by hashing the file acquired from the publication point. If the computed hash value of a 
file listed on the manifest does not match the hash value contained in the manifest, then the fetch 
has failed, and the RP MUST respond accordingly. Proceed to Section 6.6. 


6.6. Failed Fetches 


If a fetch fails for any of the reasons cited in Sections 6.2 through 6.5, the RP MUST issue a warning 
indicating the reason(s) for termination of processing with regard to this CA instance. It is 
RECOMMENDED that a human operator be notified of this warning. 


Termination of processing means that the RP SHOULD continue to use cached versions of the 
objects associated with this CA instance, until such time as they become stale or they can be 
replaced by objects from a successful fetch. This implies that the RP MUST NOT try to acquire and 
validate subordinate signed objects, e.g., subordinate CA certificates, until the next interval when 
the RP is scheduled to fetch and process data for this CA instance. 


7. Publication Repositories 


The RPKI publication system model requires that every publication point be associated with one 
or more CAs and be non-empty. Upon creation of the publication point associated with a CA, the 
CA MUST create and publish a manifest as well as a CRL. A CA's manifest will always contain at 
least one entry, i.e., a CRL issued by the CA [RFC6481], corresponding to the scope of this manifest. 


Every published signed object in the RPKI [RFC6488] is published in the repository publication 
point of the CA that issued the EE certificate, and is listed in the manifest associated with that CA 
certificate. 


8. Security Considerations 


Manifests provide an additional level of protection for RPKI RPs. Manifests can assist an RP in 
determining if a repository object has been deleted, occluded, or otherwise removed from view, or 
if a publication of a newer version of an object has been suppressed (and an older version of the 
object has been substituted). 


Manifests cannot repair the effects of such forms of corruption of repository retrieval operations. 
However, a manifest enables an RP to determine if a locally maintained copy of a repository is a 
complete and up-to-date copy, even when the repository retrieval operation is conducted over an 
insecure channel. In cases where the manifest and the retrieved repository contents differ, the 
manifest can assist in determining which repository objects form the difference set in terms of 
missing, extraneous, or superseded objects. 
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The signing structure of a manifest and the use of the nextUpdate value allow an RP to determine 
if the manifest itself is the subject of attempted alteration. The requirement for every repository 
publication point to contain at least one manifest allows an RP to determine if the manifest itself 
has been occluded from view. Such attacks against the manifest are detectable within the time 
frame of the regular schedule of manifest updates. Forms of replay attacks within finer-grained 
time frames are not necessarily detectable by the manifest structure. 


9. IANA Considerations 


The "RPKI Signed Objects" registry was originally created and populated by [RFC6488]. The "RPKI 
Repository Name Schemes' registry was created by [RFC6481] and created four of the initial 
three-letter file name extensions. IANA has updated the reference for the "Manifest" row in the 
"RPKI Signed Objects" registry to point to this document. 


IANA has also updated the following entries to refer to this document instead of RFC 6486: 


e id-mod-rpkiManifest (60) in the "SMI Security for S/MIME Module Identifier 
(1.2.840.113549.1.9.16.0)" registry 


e id-ct-rpkiManifest (26) in the "SMI Security for S/MIME CMS Content Type 
(1.2.840.113549.1.9.16.1)" registry 


e the "Security considerations" entry in the application media type registration for rpki- 
manifest 


No other actions are required. 
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Appendix A. ASN.1 Module 


RPKIManifest { iso(1) member-body(2) us(84@) rsadsi(113549) 
pkcs(1) pkcs9(9) smime(16) mod(@) 60 } 


DEFINITIONS EXPLICIT TAGS ::= 
BEGIN 


-- EXPORTS ALL -- 
IMPORTS 


CONTENT-TYPE 
FROM CryptographicMessageSyntax-2010 -- in RFC 6268 
{ iso(1) member-body(2) us(84@) rsadsi(113549) pkcs(1) 
pkcs-9(9) smime(16) modules(@) id-mod-cms-2009(58) } ; 


-- Manifest Content Type 


ct-rpkiManifest CONTENT-TYPE ::= 
{ TYPE Manifest IDENTIFIED BY id-ct-rpkiManifest } 


id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 
us(84@) rsadsi(113549) pkces(1) pkces9(9) 16 } 


id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 
id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 


Manifest ::= SEQUENCE { 
version [@] INTEGER DEFAULT @, 
manifestNumber INTEGER (@..MAX), 
thisUpdate GeneralizedTime, 
nextUpdate GeneralizedTime, 
fileHashAlg OBJECT IDENTIFIER, 
fileList SEQUENCE SIZE (@..MAX) OF FileAndHash 
} 


FileAndHash ::= SEQUENCE { 


file TIA5String, 
hash BIT STRING 


} 
END 
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Appendix B. Changes since RFC 6486 


In 2019, it came to light that multiple RP implementations were in a vulnerable position, possibly 
due to perceived ambiguity in the original [RFC6486] specification. This document attempts to 
clarify the innovative concept and application of RPKI manifests in light of real-world 
deployment experience in the global Internet routing system, to avoid future problematic cases. 


The following list summarizes the changes between RFC 6486 and this document: 


e Forbidding "sequential-use" EE certificates and instead mandating "one-time-use" EE 
certificates. 


e Clarifying that manifest EE certificates are to be issued with a validity period that coincides 
with the interval specified in the manifest eContent, which coincides with the CRL's 
thisUpdate and nextUpdate. 

e Clarifying that the manifestNumber is monotonically incremented in steps of 1. 

e Recommending that CA issuers include the applicable CRL's nextUpdate with the manifest's 
nextUpdate. 

e Constraining the set of valid characters in FileAndHash file names. 

e Clarifying that an RP unable to obtain the full set of files listed on a manifest is considered to 
be in a failure state, in which case cached data from a previous attempt should be used (if 
available). 

e Clarifying the requirement for a current CRL to be present, listed, and verified. 

e Removing the notion of "local policy". 
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